home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 691 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.7 KB
  1. Path: nntp.teleport.com!sschaem
  2. From: sschaem@teleport.com (Stephan Schaem)
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Re: Amiga programmers in deep shit...
  5. Date: 10 Jan 1996 16:58:29 GMT
  6. Organization: Teleport - Portland's Public Access (503) 220-1016
  7. Distribution: world
  8. Message-ID: <4d0r7l$i4i@maureen.teleport.com>
  9. References: <john.hendrikx.44q7@grafix.xs4all.nl>
  10. NNTP-Posting-Host: julie.teleport.com
  11. X-Newsreader: TIN [version 1.2 PL2]
  12.  
  13. John Hendrikx (john.hendrikx@grafix.xs4all.nl) wrote:
  14. : Okay, just for you I wrote a test-program to prove it is possible.  Right now a
  15. : test-program is running which reads 512 bytes from my IDE drive every VBlank. 
  16. : According to Spy the TOTAL CPU time used by my system right now is between 11
  17. : and 14% (I've got a 68030/22).  This time is distributed among the following
  18. : tasks like this:
  19.  
  20.  Thanks :)
  21.  
  22. :  SoftSCSI_ATEA.device   2.8%
  23. :  DH1                    2.6%
  24. :  DoLotsOfSmallReads     1.5%
  25. :  DisplaySpy             1.2%  (the program displaying a CPU-time graph)
  26. :  input.device           1.1%
  27. :  TopCPU                 0.5%  (the program which displayed these values)
  28. :  BOOT:C/SMouse          0.3%  (my wb-titlebar clock program)
  29.  
  30. : Only the first 3 are the ones involved with reading the data from the HD (the
  31. : SCSI-device, the filesystem and the program performing the reads).
  32.  
  33. : The DoLotsOfSmallReads program consists of nothing more than this:
  34.  
  35. :   do {
  36. :     WaitTOF();
  37. :     Read(fh,&buffer,512);
  38. :   } while(result==512)
  39.  
  40. : (I wrote it in ASM so the code above may not be correct :-) I used ASM because
  41. : I had to do several tests, and I don't want to wait 2 minutes for every
  42. : re-compile :-))
  43.  
  44.  Get the system time in tick before the read() and after:
  45.  
  46.  Because its possible that the ~14% happen once every 60 frame. 14% of 60*262
  47.  = 2200 scanline... 
  48.  
  49. :  SS>  If one can read 512byte continously in ~25 raster using read() on a
  50. :  SS>  non dma controler , I would say yes too. triple bufffer could 'smooth'
  51. :  SS>  the possible sporatic behaviour of the read()/device/HW.
  52.  
  53. : Well, see above :-)
  54.  
  55.  From your test result I see it take 14% of the system time not 14% of a 
  56.  frame wich is very diferent for what you want to do.
  57.  
  58. : As you can see above it ain't really necessary, if you can spare a bit of CPU
  59. : time.  Even with 1K or 2K block reads every frame you still beat floppies by a
  60. : long way, and without any noticeable slow-downs.
  61.  
  62.  It will work if you are garantied 80% of the frame for 'rendering'.
  63.  
  64.  I guess I can try too... create a 10meg file, and do 1k read every frame
  65.  and monitor each read() cpu usage... But then I have A3000 with a fast
  66.  scsi drive, not top of the line for that test but defenetly above an A2000
  67.  with a dataflyer and old IDE drive.
  68.  
  69.  Stephan
  70.